feat: multi-forge support — adapter pattern + Gitea#2842
feat: multi-forge support — adapter pattern + Gitea#2842afonsojramos wants to merge 26 commits intomainfrom
Conversation
github-actions
Bot
added
the
enhancement
|
@setchy I think this is a good first implementation with two forges. Now, if we want to expand this, then the login flow needs a bit of a rework. I don't mind giving it a go, but I'd rather work on that after the core implementation is there. |
… when unsupported
Adds the first non-GitHub forge adapter under the new ForgeAdapter contract: client (fetch-based, no Octokit), types, transform, and adapter registration. Wires Gitea PAT login into the Login and Accounts routes, exposes the Gitea platform icon, and gates unsupported actions (mark-as-done, unsubscribe, GraphQL enrichment) via capability flags. Adapted from work originally proposed in #2787. Co-authored-by: bircni <75789103+bircni@users.noreply.github.com>
Awesome work @afonsojramos - love the adapter pattern (i was thinking similar, borrowing from Renovates platform implementation). I'm going to pull this branch down and run it locally. We can do this in follow up PRs, but what are you initial thoughts about the reorganizing required for Also, do you think we should flag the non-GitHub forges as |
afonsojramos
force-pushed
the
multi-platform-support
branch
from
37bf36f to
4d9e45f
Compare
setchy
left a comment
setchy
left a comment
There was a problem hiding this comment.
Shall we add a section into README.md that outlines our forge adapter support matrix? we could convey current support and future potential forges perhaps
Agree with your hunch.
I’d say just go for it, given the simplicity of Gitea’s notification system. It’s nearly a strict subset of GitHub’s, so not much room to surprise people. Future forges with weirder shapes (GitLab todos, Bitbucket reviews) can land behind an |
|
| } from '../../../types'; | ||
|
|
||
| import { getCommit, getCommitComment } from '../../api/client'; | ||
| import { getCommit, getCommitComment } from '../../forges/github/client'; |
| }, | ||
|
|
||
| validateToken: (token: Token) => | ||
| token.length >= 8 && token.length <= 512 && !/[\r\n]/.test(token), |
There was a problem hiding this comment.
Gitea PATs are 40-char lowercase hex. An 8-char minimum will accept random secrets pasted by mistake.
I'd suggest ^[a-f0-9]{40}$
| function migrateLegacyAuthState(auth: AuthState): AuthState { | ||
| return { | ||
| ...auth, | ||
| accounts: auth.accounts.map((a) => ({ ...a, forge: a.forge ?? 'github' })), |
There was a problem hiding this comment.
?? only covers undefined/null. A persisted account with forge: '' or forge: 'GitHub' (case mismatch) will pass through
| repository: transformRepository(raw, account), | ||
| account, | ||
| order: 0, | ||
| display: undefined as unknown as GitifyNotificationDisplay, |
There was a problem hiding this comment.
Casting undefined through unknown defeats the type.
| id: String(user.id), | ||
| login: user.login, | ||
| name: user.name, | ||
| name: user.name as string | null, |
There was a problem hiding this comment.
RefreshAccountData.data.name is now typed; the cast is unnecessary and hides type drift
3 participants
Summary
Pivots Gitify from GitHub-only to multi-forge by introducing a
ForgeAdaptercontract (src/renderer/utils/forges/) that all forge-specific code routes through, then ports the existing GitHub modules intoforges/github/and lands a Gitea adapter as the first non-GitHub citizen.Account.forgeis a required field with a one-shot legacy-state migration; capabilities (mark-as-done, unsubscribe, GraphQL enrichment) are surfaced per-adapter so unsupported actions hide gracefully instead of silently no-op'ing.CONTRIBUTING.mdreplaces the "no other forges" stance with a multi-forge policy andMAINTAINERS.mdlists per-forge owners (Gitea: @bircni and myself). Lint is clean and 944/944 tests pass; Gitea PAT login verified end-to-end against gitea.com.Note: Gitea's notification model is absurdly simple
Closes #2786